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(54) Network independent file shadowing 

(57) Network independent ile shadowing is provided 
by the present invention. The file shadowing mechanism 
automatically and transparently stores shadow copies of 
remote file system structures when they are accessed 
by a computer. The shadow copies of the file system 
structures are stored within a shadow database that 



resides within local memory of the computer. When the 
computer becomes disconnected from a network, 
shadow copies of file system structures for the network 
are used to service requests to access such file system 
structures. 
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Description 

Tprhnical Field 

The present invention relates generally to data 
processing systems and, more particularly, to network 
independent f ile shadowing. 

Backgroun d nf the Invention 

One difficulty encountered with portable computers 
concerns accessing files when disconnected from a net- 
work Most portable computers provide facilities for the 
portable computer to be connected to a network. When 
the portable computer is connected to the network it may 
■ gain access to remote files that are stored within the net- 
work. Unfortunately, when the portable computer 
becomes disconnected from the network, the portable 
computer no longer has access to the remote files stored 
in the network. 

frjmmary fff fHa Invention 



In accordance with a first aspect of the present 
invention, a method of providing access to a f Be system 
structure from a network when a computer is discon- 
nected fromthe network is provided. The method is prac- 
ticed in a data processing system that includes a 
computer with a storage device. The computer is con- 
nectable to a first network of a first type and a second 
network of a second type. In this method, when the com- 
puter is connected to a select of one of the networks and 
a program is running on the computer, several steps are 
performed. First, a request to access one of the selected 
file system structures stored in the selected network is 
received from the program. In response to this request, 
a shadow copy of the selected file system structure is 
transparently obtained so that the shadow copies are 
obtained transparently relative to the program. The 
shadow copy of a selected file system structure is stored 
in a shadow database on the storage device. The 
shadow database holds file system structures for use 
when the computer is no longer connected to the 
selected network. 

In accordance with another aspect of the present 
invention, a method ispracticed inadata processing sys- 
tem that has a computer with a storage. The computer 
is connectabie to a plurality of networks of different types. 
At least one of the networks stores a selected f ile system 
structure. In this method, a shadow database is provided 
in the storage for storing shadow copies of file system 
structures that are retrieved for the networks. The 
shadow database includes a shadow copy of the 
selected file system structure from the selected network. 
When the computer is disconnected from the selected 
network, a request to access the selected file system 
structure is received and the shadow copy off the selected 
file system structure that is stored in the shadow data- 
base is used to service the request. 



In accordance with a further aspect of the present 
invention, a method is practiced in adata processing sys- 
tem having a computer with a storage and the computer 
is connectabie to a plurality of networks of different types. 
5 Each network includes at least one file system structure. 
In this method, when the computer is connected to the 
network, requests to access file structures of the net- 
works are received and shadow copies of the file system 
structures for which requests to access are received are 
10 stored in a shadow database in the storage. When the 
computer is disconnected from at least one of the net- 
works and a request to access a selected file system 
structure in one of the disconnected networks ts 
received, the shadow database is accessed to use a 
15 shadow copy of the selected f ile system structure to serv- 
ice the request. 

In accordance with yet another aspect of the present 
invention, a computer system is connectabie to different 
types of networks. The computer system includes a 
20 shadow database that holds shadow copies of selected 
file system structures from different types of networks. 
The computer system also includes a shadow module 
for responding to a request or access one of the selected 
file system structures by accessing the shadow data- 
25 base to obtain a shadow copy of the requested file sys- 
tem structure to service the request. The computer 
system may also include a shadow database builder for 
building the shadow database. The shadow database 
builder stores shadow copies of selected file system 
30 structures when the file system structures are accessed 
by the computer. The computer system also may include 
an agent for building and maintaining the shadow data- 
base. 



35 Rripf Descric tfrn 0* P* Drawings 

Figure 1 is a block diagram of a distributed system 
that is suitable for practicing the preferred embodiment 
of the present invention. 
40 Figure 2 is a block diagram illustrating the software 
components that play a role in practicing the preferred 
embodiment of the present invention. 

Figure 3 is a flowchart providing an overview of the 
steps performed in the preferred embodiment of the 
45 present invention. 

Figure 4 is a flowchart illustrating the steps that are 
performed to have the shadow VxD hook file input/output 
. requests in accordance with the preferred embodiment 
of the present invention. 
so Figure 5 is a flowchart illustrating the steps that are 
performed when a file I/O request is made for a remote 
file in accordance with the preferred embodiment of the 
present invention. 

Figure 6 is a flowchart illustrating steps that are per- 
55 formed by the shadow database in accordance with the 
preferred embodiment of the present invention. 

Figure 7 is a flowchart illustrating the steps that are 
performed by the agent to remove stale entries in the 
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shadow database in the preferred embodiment of the 
present invention. 

Figure 8 is a flowchart illustrating the steps per- 
formed by the agent to create sufficient free space in the 
shadow database in accordance with the preferred 
embodiment of the present invention. 

Figure 9 is a flowchart illustrating the steps that are 
performed to use the shadow database when a computer 
is disconnected from a network in accordance with the 
preferred embodiment of the present invention. 

Detailed Description of the Invention 

The preferred embodiment of the present invention 
provides network independent file shadowing. The file 
shadowing provided by the preferred embodiment is net- 
work independent in that files from different types of net- 
works may be shadowed using the mechanism of the 
preferred embodiment of the present invention. The file 
shadowing performed by the preferred embodiment of 
the present invention automatically and transparently 
keeps copies of files that are accessed by a user in a 
remote network file system. The transparency provided 
by the preferred embodiment relieves the user of the bur- 
den of selecting which files to store locally for access 
when the computer is disconnected from the remote net- 
works. 

Figure 1 is a block diagram of an illustrative distrib- 
uted system 1 0 that is suitablefor practicing the preferred 
embodiment of the present invention. Those skilled in the 
art will appreciate that the distributed system depicted 
within Figure 1 is intended to be merely illustrative and 
that the present invention may be practiced in other data 
processing system configurations. The distributed sys- 
tem 10 depicted in Figure 1 includes networks 12, 14, 
and 1 6. Each of these networks includes a file server 1 8. 
20 and 22, respectively. The file servers 18, 20 and 22 
regulate access to files and other data stored within the 
respective networks 12, 14, and 16. Each of the networks 
12,14, and 1 6 may include additional components such 
as workstations, storage devices, and other peripheral 
devices. Network 12 includes a workstation 24 with 
memory 26. The memory 26 holds a copy of an operating 
system 28 and at least one application program 30. Code 
for practicing the preferred embodiment of the present 
invention is encapsulated within the operating system 
28. Nevertheless, those skilled in the art will appreciate 
that in alternative embodiments this code may be encap- 
sulated into separate modules that are not directly incor- 
porated into the operating system. 

For purposes of the discussion below, it is assumed 
that the workstation 24 may be decoupled from networks 
14 and 16. Moreover, it is assumed that the workstation 
24 is a portable computer that is reacfily adaptable for 
use in an isolated environment. Those skilled in the art 
will appreciate that the present invention is not limited to 
practice on a portable computer, but rather may also be 
practiced on other types of computer systems. 



The preferred embodiment of the present invention 
overcomes the difficulties of the prior art described within 
the Background section by automatically and transpar- 
ently storing shadow copies of files that are accessed by 

5 the workstation 24 from remote networks (like networks 
1 4 and 1 6). As will be described in more detail below, the 
preferred embodiment of the present invention provides 
af ile shadowing mechanism and a database of remotely 
accessed files that serve as a persistent cache. The file 

10 shadowing mechanism hooks requests for file input/out- 
put (I/O) from the remote networks. The files involved in 
such requests are then brought into the persistent cache. 
Thus, while workstation 24 is connected to networks 14 
and 1 6, a persistent cache is built so that the files within 

15 the persistent cache may later be accessed when the 
workstation is no longer connected to networks 14 and 
16. 

Figure 2 is a block diagram illustrating software com- 
ponents that play a role within the preferred embodiment 
20 of the present invention. Border 37 separates the soft- 
ware components at the user privilege level from soft- 
ware components at the kernel privilege level. The file 
I/O requests are generated by the application program 
30. The application program 30 may be any type of appli- 
25 cation, including a word processing or spreadsheet pro- 
gram. Those skilled in the art will appreciate that the 
present invention also is applicable to instances wherein 
the file I/O requests are initiated from within the operating 
system 28, rather than from within an application pro- 
30 gram 30. For purposes of the discussion below, an appli- 
cation program is intended to include any program that 
can generate a file I/O request. 

The request originating from the application pro- 
gram 30 is passed to a multiple provider router 31 . The 
35 multiple provider router 31 routes the request to the net- 
work providers 33 and 35. The network providers 33 and 
35 are provided as client code in the operating system 
28. The network providers 33 and 35 include functions 
that allow a connection to be created between the appli- 
40 cation program 30 arid a remote network. The multiple 
provider router 31 passes the requests to each of the 
network providers to determine which network provider 
can successfully connect with the appropriate network. 
Separate network providers 33 and 35 are provided for 
45 each of the different types of networks within the distrib- 
uted system 10. The preferred embodiment of the 
present invention provides a shadow network provider 
which is used when none of the other network providers 
33 succeed in establishing a connection. The shadow 
so network provider 35 is used to establish a shadow net- 
work connection to the shadow database 42 so that the 
data contained therein may be accessed. The use of the 
shadow network provider 35 will be described in more 
detail below. The network providers 33 and 35 may 
55 establish a connection to a remote network by directly 
interacting with the file system drivers 38 and 40, which 
will be described in more detail below. Alternatively, the 
network providers 33 may establish connections to 
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remote networks via the installable file system manager 

32 ' The IFSMGR 32 is included as part of the operating 
™, 8 and i S responsible for directing file I/O 

server for handling the request). The IFSMGR 32 is 

mav access files in different file system types. 

The IFSMGR 32 interacts with file system drivers 
(FTO? I keFSDs 36. 38. and 40. which are shown in 10 
SS?k te FSDS 36, 38. and 40 serve as imerfaces 
between the IFSMGR 32 and the file systems. The FSDs 
the system as device drivers. SpeoficaHy. the 
^Ds 36. 38, and 40 are viewed as dev.ce drrvers that ^ 
arp resDonsible for a file system. 

T^TfIds 36. 38. and 40 are part of the operaUng 
svstem 28 The FSDs 36. 38. and 40 may interface wrth 
^systems (like FSC .36] .or remotefile ^sterns 
(like FSDs 38 and 40). Each of the FSDs ^36 , 38, and 40 
s designed to interface with a given file system. 

Te Sadow VxD 34 is a virtual device driver for 
monitoring file I/O requests to determine ag^he 
to be placed within the persistent cache (known as the 
^alcw datable 42). The sh^ 
device driver that simulates a device ^™P?££ 
the virtualization of a device). The shadow VxD 34 js 
Elemented as part of the kerne, of the openrtmg ^sys- 
tem 28. The responsibilities of the shadow VxD 34 will 
Kfl riacriihed in more detail below. 

what file type should be included and exd^ rrom he 
S hadcJd^se42.Thehimsdatabaseartsl ! kea^ 

toS or exclude certain file references. The Nnts 
da^sealsoactslikeaworkqueuefortheagem.^ 

the agent may periodically fill in **<^«"£l?" 
Tries in the hints database, regardless of whether the 
Svebeen referenced by any other appn^onprc, 
gram Ahirrtsdalabasetri^ 
local disk space in order to optimize the space that is 
^.tfTme user when the user s computer ,sd,s- « 

^Ir^SSse 42 holds comp.ete naming 

28 (Fiaure 1) and that are within a remote file system 
Se ( Xowdata b ase42a.soho.d S are P resentat^of « 

2T«. that is accessed (/.e.. either a sparse rjp~£ 

mXmZL which have a higher priority for remaining 
S the shadow database 42 thar 

An application, known as an agent 44. is P rDV,ae ° 
to maintain the shadow database 42. As will be 
described in more detail below, the agent 44 J^^f^^^l. " 
STawoken to bring f iles into the shadow database 42 
and to update the shadow database as needed. 

Rgure3 is a flowchart showing an overv^crfthe 
steps L are performed by the preferred embedment 



of the present inverrton. Initially, a workstatton 24. scon- 
nerftd to networks 1 4 and 1 6 (step 46 in F.gure S^The 
S« database 42 is then built as will be desotoedjn 
mo^eteil below (step 48 in Figure 3). Late, the work- 
Sation 24 becomes disconnected from one or more of 
£ netwtte Tl4 and 16 (step 50 in Figure 3). While the 
l«24ren^ 

the shadow database 42 is used as a persistent^ cache 
Sat is accessed to locate files that ongmated from 
E£ ^systems (step 52 in Figure 3) ^The works*- 
tion24then reconnects to the networks (step ,54, ^Figure 
3) and various clean-up activities are performed (step 

56) ' The shadow VxD 34 is responsible for hooking the 

file I/O requests to remotefile systems. R ^ e4 ' s ^ 
chart thatillustratesthestepstratareperformed to ena- 

WeSrSadowVxD34toperformsuchhook.ng.lnrt.ally. 
during system boot, the IFSMGR 32 is loaded into "2®™" 
Try 26 the workstation 24 (step 58 .n Figure i^Once 
Z IFSMGR 32 is fully loaded. 
loaded (step 60 in Figure 4). The shadow VxD 34 hoote 

Recalls to the ^^^^S5m 
remote file system drivers wrth the IFSMGR^ 32 ^step 62 
in Figure 4). The remote file system drivers 38 and 40 
are Sen loaded subsequently (step 64 in F.gure 4) The 
ReaisterNet service registers remote networks wrth the 

ce^e shadow VxD 34 can hook each file I/O request 
Stte serrtfromthe IFSMGR 32 to one of theremotefile 

,oaded. they call the Registers serv.a sthat proved 
by the IFSMGR 32 to register the FSDs. TheFSDs 38 
and 40 forward a function pointer to make a connection 
tol^systemdrrveras^^^^ 
service Subsequently, when the IFSMGR 32 neeos a 
Sn^on U toSmJe. Y^^JJ 
tified by the pointer that is passed from the > FSD 38 ^or 

an arrav of function pointers to the IFSMGR 32- Tns 

or 40. The shadow VxD 34 hooks the J***^ 
Uom the FSD 38 and 40 and receives the array of fur*. 
Jointers. The shadow VxD 34 passes rts own array 

vTdS^SSs into functions of the shadow VxD 
^/Taresutt each time that an operation e to be per- 
form^ on one otthe remote file systems, the shadow 
5S£ hcX these calls and fills the shadow database 

42 "SSRS a f .owchart illustrating the steps that are 
perS* the preferred *"*^£%S£ 
invention when an I/O request <™^J™!£ !! 
!on program 30. The process is inrtated by the appbea 
™ SSram 30 making a file I/O request to a file that 
SEES." the remote networks (step 66in Figure 
5 y aTw^s discussed above, this remote «e I/O request 
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may originate from any program that is running on the 
local workstation 24. The request is passed to the IFS- 
MGR 32 (step 68 in Figure 5). The shadow VxD 34 hooks 
the request (step 70 in Figure 5) and adds the file to the 
shadow database 42 if it is not already present within the 5 
shadow database (step 70 in Figure 5). In particular, 
complete naming information for the requested file is 
stored within the shadow database 42. This complete 
naming information includes a pathname for the server- 
share pair as specified according to the unified naming 10 
convention (UNC). The files are stored within the data- 
base 42 in a sparse format (i.e., the contents of the file 
are not stored immediately therein). The shadow VxD 32 
then passes the file I/O request to the proper FSD so that 
the appropriate file is retrieved (step 74). 15 

As was mentioned above, the role of the agent 44 
(Figure 2) is to maintain the shadow database 42. One 
of the primary roles of the agent 44 is to retrieve the con- 
tents of files that are stored sparsely within the shadow 
database 42. The agent 44 performs this task as a back- 20 
ground thread. Figure 6 is a flowchart illustrating the 
steps that are performed by the agent 44 in this capacity. 
Initially, the agent 44 is awoken on a periodic basis (step 
76 in Figure 6). For example, the agent 44 may be 
awoken every 30 seconds. It is then active and subse- 25 
quently put back to sleep. When the agent is awoken it 
looks at the entries within the shadow database 42 and 
identifies entries that are stored in sparse form (step 78 
in Figure 6). The agent 44 begins looking for sparse 
entries at the top of the priority queue and then proceeds 30 
down to lower priority entries. When the agent 44 locates 
a sparsely stored entry, the agent attempts to fill in the 
contents of the file by grabbing a shadow copy of the file 
(step 80). The agent 44 is then put back to sleep after 
the fixed period of time elapses or after the agent has 35 
nothing further to do (step 82). 

The agent 44 is also responsible for maintaining the 
shadow database 42. One difficulty is that copies of files 
stored within the shadow database 42 may become stale 
or too old. Each time a file is retrieved and stored within 40 
the shadow database 42, a timestamp is entered in the 
database. This timestamp is used as shown in Figure 7 
to remove stale entries from the shadow database 42. In 
particular, the agent 44 examines the timestamp for files 
stored within the shadow database 42 (step 84 in Figure 45 
7). The shadow VxD may perform this examination on 
opening of the files in the shadow database or at other 
suitable times. The timestamp is compared to a prede- 
termined timestamp value to determine if the file is stale 
or not (step 86). Any timestamps with values earlier than so 
the cutoff timestamp value are targeted for removal. If a 
file is determined to be stale, a new copy of the file is 
retrieved and stored within the shadow database 42 
(step 88 in Figure 7). 

Another difficulty that the agent 44 must address in ss 
maintaining the shadow database 42 is that the size of 
the shadow database 42 is fixed and hence, may 
become full. For example, the shadow database 42 may 
constitute a fixed size portion of a hard disk drive for the 



workstation 24. As more files are brought into the 
shadow database, there is an increasing likelihood that 
the shadow database 42 will become full. In such an 
instance, certain files must be removed from the shadow 
database. As shown in Figure 8, the agent 44 determines 
that insufficient space is available (step 90 in Figure 8). 
This determination may be made upon writing to the 
shadow database 42, upon each opening of a file in the 
shadow database, or at other alternative times. The 
agent 44 begins deleting the lowest priority files on a one- 
by-one basis until sufficient space in the shadow data- 
base 42 is available (step 92 in Figure 8). 

As was discussed above, the shadow database 42 
is built while the workstation 24 is connected to the net- 
works 1 6 and 1 8. The shadow database 42 is used, how- 
ever, primarily when the workstation 24 is disconnected 
from one or more of the networks 1 6 and 18. Figure 9 is 
a flowchart illustrating the steps that are performed to 
use the shadow database 42 when the workstation 24 is 
disconnected from one or more of the networks 16 and 
18. The application program 30 is running on the work- 
station 24 and initiates a file I/O request for a file on a 
remotef ile system (step 94 in Figure 9). The multiple pro- 
vider router 31 determines that the conventional network 
providers 33 cannot be used to realize a connection to 
the network that holds the file in the remote file system 
and, thus, routes the request to the shadow network pro- 
vider 35. which calls the shadow VxD 34 to access the 
shadow database 42 (step 96 in Figure 9). The shadow 
VxD 34 then becomes active and looks within the 
shadow database 42 (step 98 in Figure 9). The shadow 
VxD 34 checks whether the file is in the shadow data- 
base 42 and present (i.e., not in sparse form) (step 100 
in Figure 9). If the file is stored within the shadow data- 
base 42, it is retrieved and used (step 102 in Figure 9). 
On the other hand, rf the file is not within the database 
or is merely stored in sparse form, an error indicating that 
the file is not available is returned (step 104). 

When the workstation 24 is reconnected with one or 
more of the networks 14 and 1 6, a file server 1 8 and 20 
of the network must examine the local copies of files held 
at the workstation 24 and reconcile these copies with 
those held in the network. Standard reconciliation tech- 
niques may be utilized. The agent 44 may include code 
for checking whether a given file server is online or not. 
When the server is online and local files have been mod- 
ified, the integration and reconciliation is triggered. 

While the present invention has been described with 
reference to a preferred embodiment thereof, those 
skilled in the art will appreciate that various changes in 
form and detail may be made without departing from the 
intended scope of the present invention as defined in the 
appended claims. 

Claims 

1 . In a data processing system having a computer with 
a storage device and that is connectable to a first 
network of a first type and a second network of a 
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second type, wherein the f irst network and the sec- 
ond network each store file «^J*^ re V* 
method of providing access to one of the file system 
structures from one of the networks when the com- 
puter is disconnected from at least one of the net- 
works, comprising the steps of: 

when the computer is connected to a 
selected one of the networks and a program is run- 
ning on the computer, 

(i) receiving a request to access a selected one 
of the file system structures stored on the 
selected network from the program; 

(ii) in response to the request, transparently 
obtainingashadowcopyoftheselectedfilesys- 

tem structure relative to the program; and 

(iii) storing the shadow copy of the selected f de 
system structure in a shadow database on the 
storage device which holds file system struc- 
tures connected to the selected network. 

2. The method of claim 1 . further comprising the steps 

° f ' when the computer is disconnected from the 
selected network, 

r.) receiving a request to access the selectedfile 
system structure of the selected networked 
(ii) using the shadow copy of the selected if He 
system structure that is stored in the shadow 
database to service the request 

3. The method of claim 2, further comprising the step 
of flushing the shadow database tc ^move all Me 
systemstructures for the selected network whenthe 
computer is reconnected to the selected network. 

4. The method of claim 1 . further comprising the steps 

° f " before storing the shadow copy, determining 
that there is insufficient free space in the shadow 
database to store the shadow copy; and 

deleting We system structures in the shadow 
database to create sufficient free space to store the 
shadow copy of the selected file system structure. 

5. The method of claim 1 wherein the ^date- 
base is a priority queue that storesfde system sfruc 
turesinthepriority queue accordingtopnon^rfthe 

file system structures and wherern the selected Me 
system structure has a priority and said step offer- 
ing the shadow copy of the selected fde system 
structure at a location in the priority queue is based 
on the priority of the selected file system structure. 

6. in adata processing system a comber with 
astoragearrfbeingwnnectabletoaplural^et- 

works of different types wherein at least a selected 
one of the networks stores a selected f.le system 



structure, a method of providing access to the 
selected file system structure when the computer is 
disconnected from theselected network, compnsmg 

the steps of: 

providing a shadow database in the storage 
tor storing shadow copies of file system stmctures 
that are retrieved from the networks. said shadow 
database including a shadow copy of the selected 
f ile system structure from the selected network; 

when the computer is disconnected from the 
selected network, 

(i) receiving a request to access the selectedfile 
system structure; and 

(ii) using the shadow copy of the selected file 
system structure that is stored in the shadow 
database to service the request. 

7 The method of claim 6 wherein the step of providing 
the shadow database comprises the step of provid- 
ing the shadow database as a priority queue 
wherein each shadow copy of afile system structure 
has a priority and a position of each shadow copy 
within the queue is determined by its priority. 

8. ThemethodofclaimewhereinthecOTputersystem 
runs an application program and wherein the appli- 
cation program generates the request to access ithe 
selected file system structure and wherein said step 
30 dusingtheshadowccpycrftheselect^filesystem 
structure to service the request is performed trans- 
parently relative to the application program. 

9. The method of claim 6. further comprising the steps 

35 ° f " when the computer is disconnected from a 
second of the networks. 



40 



45 



(i) receiving a request to access a ffle system 
structure in the second network; and 

(ii) using a given shadow copy of the file system 
structure to be accessed from the second net- 
work to service the request, the given shadow 
copy being stored in the shadow database. 

10. in a data processing system having a ^P*er with 
astoragearKJbeingconnectab.etoap.ura.^et- 

works of different types wherein each network 
includes at least one ffle system structure, a method 
so comprising the steps of : 

when the computer is connected to the net- 
works. 

(i) receiving requests to access file system 
« structures in the networks; 

Scoring shadow copies of the file system 
structures for which requests to access are 
received in a shadow database in the storage; 
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when the computer is disconnected from at 
least one of the networks and a request to access a 
selected file system structure in one of the discon- 
nected networks is received, accessing the shadow 
database to use a shadow copy of the selected file 5 
system structure stored therein to service the 
request 

1 1 . The method of claim 1 0 wherein each shadow copy 

of a file system structure stored in the shadow data- 10 
base has a priority and said step of storing shadow 
copies of the file system structures for which 
requests to access are received in the shadow data- 
base in the storage comprises the step of storing the 
shadow copies as a priority queue wherein a posi- is 
tion of each shadow copy within the priority queue 
is determined by its priority. 

12. The method of claim 10 wherein the step of storing 
shadow copies comprises the steps of: 20 

determining that insufficient free space is 
available in the shadow database to store a given 
one of the shadow copies; 

deleting shadow copies from the shadow 
database to provide suff icient free space to store the 25 
given shadow copy. 

1 3. The method of claim 1 0, further comprising the steps 
of: 

storing a timestamp for each shadow copy in 30 
the storage, each timestamp indicating when the 
shadow copy was stored in the shadow database; 

storing updated versions of shadow copies 
when the timestamps indicate that the presently 
stored shadow copies are too old. 

14. A computer system that is connectable to different 
types of networks comprising: 

a shadow database holding shadow copies 
of selected file system structures from different 40 
types of networks; and 

a shadow module for responding to a request 
to access one of the selected file system structures 
by accessing the shadow database to obtain a 
shadow copy of the one file system structure to serv- 45 
ice the request. 

15. The computer system of claim 14 ( further compris- 
ing a shadow database builder for building the 
shadow database by storing shadow copies of the so 
selected file system structures when the file system 
structures are accessed by the computer. 

16. The computer system of claim 14, further compris- 
ing an agent for maintaining the shadow database, ss 

17. The computer system of claim 14, further compris- 
ing file system drivers for interfacing with file sys- 
tems of the networks. 
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